home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 716 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  3.9 KB
  1. Subject: Re: Gem Listing (fwd) 
  2. Date: Fri, 08 Jul 1994 18:16:04 +1000
  3. From: Warwick Allison <warwick@cs.uq.oz.au>
  4. Precedence: bulk
  5.  
  6. Ken Hollis:
  7. >WHAT is so INCREDIBLY DIFFICULT about using objc_find to locate the editable
  8. >object under the mouse??  HERE IS SOME EXAMPLE CODE!!!!!!
  9.  
  10. Ken, I agree, that way is very easy to code.  The problem is whether it
  11. is of sufficiently low cost to impose it as a standard for applications
  12. to follow.  
  13.  
  14. The are two techniques for providing hot objects:
  15.  
  16.     1) Wait for mouse to move out of 1x1pixel area,
  17.         then use objc_find to work out what it is over.
  18.  
  19.     2) Work out the largest rectangle around the mouse for
  20.         which all mouse positions are above the same class
  21.         of hot object, eg. those for which there will be
  22.         no cursor change, then wait on this area rather
  23.         than the 1x1 pixel area.
  24.  
  25. (1) is easy to code (thank you Ken), but an inefficient use of
  26.     events, as if 5 multitasking programs do this, then for
  27.     every motion of the mouse, each of those programs will
  28.     be woken up and each will call objc_find.  In many cases,
  29.     the objc_find will be very short, but it is still a system
  30.     call for each application for every motion of the mouse.
  31.  
  32. (2) is more difficult to code, but is optimal in efficient use
  33.     of events, as events are infrequently generated.
  34.  
  35.  
  36. If pressed to implement it, I'd probably cop out and use (1).  If I _wanted_
  37. to implement it properly for a serious application library that supported
  38. a standard, I would be obliged to use (2).
  39.  
  40.  
  41. Therefore, I'm arguing against using hot objects for window objects because
  42. I neither want to use an inefficient cop-out solution nor invest the effort
  43. into the thorough solution for the sake of a non-GEM, pretty on-screen
  44. effect.
  45.  
  46.  
  47. >I think you COMPLETELY missed what the entire idea of a GEM Master Listing
  48. >was for.  Take, for example, the Cookie Master Listing.  GEM Master Listing
  49. >provides exactly that same purpose:  It tells programmers which Extended
  50. >Object Types (and such) have already been used, and if they wish to make
  51. >their programs compatible with those types, they refer to this list.
  52.  
  53. There are 4 billion available cookies.  Cookies are a global resource, while
  54. extended object types are not (multiple applications can be using the same
  55. extended object types for different purposes at the same time)... which is
  56. just as well, as thjere are only 256 of them.
  57.  
  58. >What if you used some GEM library, say E_GEM. Now say you wrote a program
  59. >around it, and then decided to dump E_GEM in favor of some other (newer)
  60. >library? If E_GEM didn't follow the listing and decided to assign messages
  61. >and indices hodge-podge, your task would be damn near impossible.
  62.  
  63. But if all GEM libraries are the same, why would you change from one to
  64. another?  GEM++ for example doesn't even use the Extended Object Types
  65. byte.  It uses full parameterized object instantiations presribed in
  66. the code, allowing any number of different types of object from sliders
  67. to scrolling self-drawing objects.
  68.  
  69.  
  70. >Also, for programmers wanting to exchange messages and events with other
  71. >programs, the GEM Master listing is a handy reference.
  72. >
  73. >If you like to live in your own proprietary world and never ever intend on
  74. >exchanging messages or events with any other programs, then maybe you don't
  75. >need the GEM Master listing.
  76.  
  77. What do you think Drag And Drop is for?  Exactly what sorts of messages
  78. do you have in mind?  If I write a pair of apps that send each other messages,
  79. they can use whatever protocol I want, as it is not a shared resource.
  80.  
  81. For broadcast messages, you have a point, but collecting non-broadcast
  82. message types is of no relevance.  How many new broadcast message types
  83. currently exist?  0? 
  84.  
  85. >This is analagous to the problem with vector sharing, and is essentially
  86. >the reason why XBRA (and the XBRA registration list) was created.
  87.  
  88. Not at all.  XBRA doesn't reply on some central list of unique identifiers.
  89. It relies on programs following a fixed standard.
  90.  
  91.  
  92. --
  93. Warwick
  94.